Abstract
The purpose of this paper is to define the Organization of an Automated Testing Architecture that is application independent. Meaning, the architecture is independent of the type of application or the coding language.
The three organizing principles of an independent automation architecture are as follows:
- One Point Maintenance
- Data Driven
- Test Case Independence
This article will address the first principle: One Point Maintenance.
Introduction
The world of automated testing has expanded and become more sophisticated over the last twenty years. It has become commonplace to use automation to accelerate testing and is integrated into new methodologies such as Agile, Test Driven Development and others. The value and rationale has been established and the debate is basically over.
There is a great deal of literature on this topic such as 1) Tool selection, 2) Ease of use, 3) How to get started, 4) How to be successful and so on.
From the point of view of the author, what is lacking is how to organize, build and maintain an Architecture that is application independent.
The reason this is so important is that it.s the architecture that is the determining factor for success regardless of any other particular criteria.
Frameworks versus Architecture
Frameworks
One point of discernment is the difference between an architecture and a framework as the terms are often used interchangeably.
Framework typically refers to the various components or qualities of an automation system, such as; 1) Re-usable modules, 2) Common functions such as a .login. or .place an order. function., 3) Results and error logs, 4) Drivers that call sets of cases, 5) Ease of use and so on. There is a relatively long list of framework components.
Frameworks, from this point of view, are mostly organized around the concept of .Common.. That is, what are the common elements, tasks or qualities that can be identified and combined to reduce redundancy and increase efficiency?
Frameworks are an essential part of an automated testing system; however, the position taken here is that it.s the Architectural design which allows for the development of the framework.
We will now focus on the topic of an Automation Architecture, emphasizing the three organizing principles and their .taken for granted. assumptions.
Architecture
As stated in the abstract; The three organizing principles of an independent automation architecture are as follows:
- One Point Maintenance
- Data Driven
- Test Case Independence
One Point Maintenance
One Point Maintenance is the primary organizing principle of the architecture. It refers to the ability to make one change, in one place; that will automatically updates a large number of test cases.
This principles ensure that the code will not be redundant and that the automated testing system can quickly accommodate application changes.
It will prevent the system from slowing down the automated testing effort or becoming a "bottleneck" for the QA team, it allows the QA team to meet time project time constraints. This one principle will undermine most objections to automated testing as one point maintenance reduces cost, increases coverage, and saves time and effort to keep the system up and running.
An Example of One Point Maintenance
I once worked for a healthcare provider where I was responsible for the automated testing of an enterprise wide electronic medical record system that had more than eight million users nationwide. Note: from the point of view of One Point Maintenance the platform is not relevant.
One end-to-end test we automated navigated around thirty (30) screens; here is a high level summary:
- Patient
- Login
- Make an appointment
- Logs out
- Physician
- Logs In
- Enters a diagnosis
- Prescribes medication
- Follow up appointment
- System
- Records the appointment date and sends an email to the patent
- Records the next appointment date and sends a confirmation email
- Based on the patient's medical coverage
- Enter the cost of the appointment
- The cost of the medications
- Updates the patents out of pocket deductibles accumulator
- Send out a receipt
The health provider has hundreds of different policies, deductibles varied depending on the policy type and other variables. There are literally thousands of significant variations of this test scenario, which will be referenced when providing examples of the other two principles; Data Driven and TestCase Independence (see later papers).
Given the complexities of the test case, how does one apply the principle of One Point Maintenance with automated testing? Here are the steps to follow:
- Build a separate function and error handler for each screen
- One function - one screen (or window)
- One error handler for each screen
- This function only deal with the objects and navigation properties of the one screen, regardless of the nature of that screen.
- The error handler is devoted to unexpected conditions that may arise on that one screen
- The login screen has two or three objects while the Patient Appointment screen may have thirty of forty objects, according to the Principle, there is still one function per screen regardless of its complexity
- As each screen is used by literally thousands of test cases, building a separate function for each screen is how to apply the principle of One Point
- When changes are made to screens, the automation engineer, makes updates to the individual functions for that screen
- The Maintenance is .One Point. due to applying this architectural principle. Instead of making hundreds of changes across the system which can get confusing and error prone, all that is required is to locate the individual screen function and make the updates in one time at One Point
Summary: One Point Maintenance - Principle One (OPM)
The application of this architectural principle, One Point Maintenance, implies the individual building the system understands its intrinsic value and implements throughout the design and implementation of the system.
The actual implementation begins by defining the navigation sequence for each test scenario which includes all the screens or windows and associated error handlers.
The screen or window is the first point of reference, sometimes referred to as .Object Page Reference.. The reason for bringing up this topic now is that OPM requires a point of reference that groups a set of equivalent objects and encapsulates the user experience. That is, the user navigates from screen to screen, to complete a task, such as placing an order. The equivalent objects exist on one screen; consequently, when an object changes, one screen update is all that is required from a maintenance point of view.
OPM implementation takes place at the screen level and enabling the engineer to easily keep up with application changes.
Let's discuss the importance of error handlers for a moment in regard to the principle of One Point Maintenance.
- Error handlers
- Differentiate between hard and soft error or messages
- Used for negative testing
- Verifying the error or warning message is correct and is display at the appropriate time and place
- Designed to handle modal windows
- One error handler for each navigation screen
OPM applies to error handling scripts in the same manner as navigation screens. The engineer creates one error handler for each screen so as new error, or warning, messages display the .single. point to code for their occurrence is clearly defined. Thereby maintaining the OPM architectural principle throughout the automation framework.
Continuous thinking of OPM and consciously designing it into the automation framework will result in an automated testing system that is easy to maintain, fast to update and has the capability to scale as needed.
